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(54) System for providing a trustworthy user interface 



(57) The preferred embodiment of the invention 

comprises a computer system which employs a trusted 
display processor (260), which has a trusted processor 
(300) and trusted memory (305, 315, 335, 345) 
physically and functionally distinct from the processor 
and memory of the computer system. The trusted display 
processor (260) is immune to unauthorised modification 
or inspection of internal data. It is physical to 
prevent forgery, tamper-resistant to prevent 
counterfeiting, and has crypto functions (340) to 
securely communicate at a distance. The trusted display 
processor (260) interacts with a user's smartcard (122) 
in order to extract and display a trusted image, or 
seal (1000), generate a digital signature of the bitmap 
of a document image and control the video memory (315) 
so that other processes of the computer system cannot 
subvert the image during the signing process. The user 



interacts with the trusted display processor via a 
trusted switch (1.35). 
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Description 

Tprhnical Field 



roiatoc to anoaratus and methods for providing a user interface in a system, and in 

trustworthy fashion. 
Rark ground Art 

- [OOOu, Co—lphoradmaosm,*^ 

competing products such as the Apple anM . Mi( , p dome P s , c or consume( , and 

computer Generally, markets lot suoh machines tall into wo <****£™ consumer use is a relatively nigh 
corwata. A ^^1^^^^!^^ games. For «s type of 

• 5SSJ SS£T5ES»5»" 95 anO •> open*, system products and Inte, propose. se-ca,*d 
WinTelpla«o™ S dominate Ote^rkei comI)uter platrarm 

[0003] On the other hand, tor business use. tneri a v multi-national organizations. In many of 

solutions available aimed at organizahons ranging tta s^ tHyT" applied functionality for a 
these applications, a server platoon provides MM ^/"^.ity. remote access, networking 

20 S jLtlCt^SM rio^SorntT a o^peraung sysr.m la oommon. as 

ySTS Z KT S^rjTP-SX. - ~- applications * d,a,og Ooyes 
and drop-down (or pull-up) menus. . thp lnterne t known as "e-commerce", there has 

manipulation of electronic data, in such p 0 P osa, ^ l ' y n ^ U ™^ ^ rke t place have so far been held back. The 

sees =s : s?£ ^zra^srsiK - — «— — - 

platforms, for the making of such transactions^ increasing the security and trustworthiness 

" T^uter^^ 

the market which Mud. a "^^^'"^ SS^^lT^n extras' to conventional persona, 
on the computer. Presently, such smartcards are at me 'eve. ° « Although these prior art schemes go 
computers, and in some cases are integrated into the levels of Tecurity an I Sstworthiness gained by prior 

some way to improving J ^widesp ead appSn'of automated transactions between 

value^ansa^ns to _ commerce on a widespread 

scaTmeywil. require greater confidence in the 9930110 0.6, filed at the 

100071 in the applicant's co-pending patent apph^feons Tru^ed Computing Platform «3 computing 
European Patent Office on ^ February 1999 ^d 'Comp^ 

Apparatus' 9905056.9, filed at the ^^^J^^^JS^SS^ comprising a computing platform 

sfrr a rse^^^ — ,s — 

compared to the case where no trusted component is present, because: 

. A user of a computing entity has higher confidence in the integrity and security of his own computer entity and 
55 in the integrity and security of the computer entity belonging to the other party; 

. Each entity is confident that the other entity is in fact the entity which it purports to be, 



Printed from Mimosa 09/27/01 12:22:21 page-.*- 




EP 1 056 014 A1 

• Where one or both of the entities represent a party to a transaction, e.g. a data transfer transaction, because 
of the in-built trusted component, third party entities interacting with the entity have a high degree of 
confidence that the entity does in fact represent such a party; 

5 

• The trusted component increases the inherent security of the entity itself, through verification and monitoring 
processes implemented by the trusted component: and 

• The computer entity is more likely to behave in the way it is expected to behave. 



[0008] While the concept of a trusted component as described in the co-pending application goes a long way to 
providing to a user with a substantial degree of trust in a computer platform, there are still times when the user 
requires an even higher degree of trust in his equipment, for example during an electronic transaction, such as 

15 digitally signing a document, or transferring funds from the platform to a remote platform. 

[0009] As has been indicated above, the conventional method of signing a document is to physically write a 
signature on the medium (usually paper) upon which an image of a document is reproduced. This method has the 
advantages that it is clear what is being signed, and the signed image is proof of what was signed. However, it does 
not meet the needs of e-commerce. 

20 [0010] Nowadays it is also possible to digitally sign a document, using a conventional computer platform and 
standard encryption techniques. In conventional computer platforms, however, the present inventors have appreciated 
that the electronic rendition of a document which is digitally signed is typically not the same rendition of the 
document that is visible to the user. It is therefore possible for a user to unintentionally sign data that is 
different from that which he intended to sign. Conversely, it is also possible for a user to intentionally sign data 
and later fraudulently claim that the signed data does not correspond to that displayed to him by the computer 
platform. Such problems would still be the present, even if a trusted platform, as described above, were used. 
[0011] Conventional electronic methods of signing are well known to those skilled in the art. Essentially, 
digital data is compressed into a digest, for example by the use of a hash function. Then that digest is encrypted 
by the use of some encryption method that has been initialised by a secret key (or simply a 'secret 1 ). This is 
normally done on a computer platform, such as a PC. One implementation is to sign data using a private encryption 

30 key held secret on a user's smartcard, which is plugged into a smartcard reader attached to the computer platform. In 
the specific case of a textual document, the digital data may be the file produced by a word processor application, 
such as Microsoft's Notepad, Wordpad, or Word. As usual, the act of signing implies that the signer accepts some 
legal responsibility for the meaning of the data that was signed. 

[0012] Hash functions are well-known in the prior art and comprise one way functions which are capable of 
35 generating a relatively small output data from a relatively large quantity of input data, where a small change in 
the input data results in a significant change in the output data. Thus, a data file to which is applied a hash 
function results in a first digest data (the output of the hash function). A small change e.g. a single bit of data 
in the original data file will result in a significantly different output when the hash function is reapplied to the 
modified data file. Thus, a data file comprising megabytes of data may be input into the hash function and result in 
40 a digital output of the order of 128 to 160 bits length, as the resultant digest data. Having a relatively small 
amount of digest data generated from a data file stored in the reserved directory is an advantage, since it takes up 
less memory space and less processing power in the trusted component. 

[0013] During known signing processes, a user will typically interpret a document as it has been rendered on the 
computer's monitor at normal magnification and resolution. In existing applications, the user's smartcard signs data 
45 in a format that is the representation of the document by the application used to create and/or manipulate the 
document. The present inventors believe, however, that there is potential for software to send data to the smartcard 
that has a different meaning from that understood by the user when viewing the screen. This possibility may be 
sufficient reason to introduce doubt into the validity of conventional methods of digitally signing electronic 
representations of documents that are to be interpreted by people. 

50 

Disclosure of the Invention 



[0014] The present invention aims to provide a user with greater trust during a trusted operation by providing a 
trusted user interface. 

[0015] In accordance with a first aspect, the present invention provides a data processing system capable of 
operating in a trusted operating mode, the data processing system comprising: 

main processing means for executing at least one application process; 
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ro0281 As will become apparent, the trusted component according to the preferred embodiment herein provides a 
functions of the host computer. m ^a^ vA/ith Qimiiar DroDerties is associated with 

STHE.TS57. a-rssK: ^sr^sr.-iisss 

present embodiment as will be descnbed. 

r00331 Fiqure 2 shows a hardware architecture of the host computer of Figure 1 . 

S3 4o«, 9 „ R9U „ 2. *. no., = - ™ R ~J a ToM 2 TTo?S Ta 
Drocessor connected to main memory, which comprises RAM <>U5 ana rcuivi t . . 

which is beyond the scope of the present description, the reader ,s referred to the book The ' nd ' s ^awe 

ST 5 ™ ^^SK5S5T?«. -st computer 100 attached to the PC. bus 225^ a SCS. (small 
SSL system -rface) adaptor connected via ^ 

LAN (local area network) adaptor 250 for connecting the host computer 100 to a w ' ^ d 
100 can communicate with other host computers (not showr * such as if* servers, J^T^^SlILl reader 
the internet 130; an IO (input/output) dev.ce 225, for attach ng aTstandard display functions plus 

12 0; and a trusted display processor 260. The trusted ^^^^^^XS^ are those functions 
a number of further tasks, which will be descnbed in « eta .I below S ^ Td fo f^~ PC operating un der the 
that one would normally expect to find in any standard host ^"^^ ^ or application 

Windows NT™ operating system, for displaying an image associated ^^'^S^Mas well as a direct 
software. It should be noted that the keyboard 110 has a connection to the IO dev,ce 255. as wen 
connection to the trusted display processor 260. nrocesS or 260 are preferably also integrated 

r00361 All the main components, in particular the trusted display processor jxm are pre y 
onto me momerboard 215 of the host computer 100. although, sometimes. LAN adapters 250 and SCS. adapters 
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smart card in order to recover seal image data from the smart card; 

Figure 8 is diagram which illustrates the sequence of messages between the trusted display processor and the 
smart card in order to generate a signature of a document image; 

Figure 9 is diagram which illustrates the sequence of messages between the trusted display processor and the 
smart card in order to generate a signature of a summary of the document image signing process; 

Figure 10a is a diagram which illustrates an exemplary trusted image; 

Figures 10b to 10d are diagrams which illustrate the visual steps in signing a document image; and 

Figures 10e to 10g are diagrams which illustrate alternative ways of highlighting the image of a document to be 
signed. 

Best Mode For Carrying Out the Inventi on, & Industrial Applicability 



[0021] The preferred embodiment utilises a trusted component that most conveniently uses some of the 
characteristics of the 'trusted component' described in the applicant's co-pending European patent application 
20 number 99301100.6. In that application, the trusted component is a hardware device, comprising a processor 
programmed to measure an integrity metric of its host computer, compare it with a true value of the integrity metric 
and communicate the integrity (or otherwise) of the host computer to users or other host computers. The significant 
similarities between that trusted component and the trusted component in the preferred embodiment herein are: 

25 that they both use cryptographic processes but preferably do not provide an external interface to those 

cryptographic processes; 

that they are both tamper-resistant or tamper-detecting, so that their operation cannot be subverted, at least 
without the knowledge of the legitimate user: and 



that they both preferably consist of one physical hardware component that is both physically and functionally 
independent of the host computer on which it resides. 



[0022] Such independence is achieved by the trusted component having its own processing capability and 
memory. 

[0023] Techniques relevant to tamper-resistance are well known to those skilled in the art of security, as 
described in the applicant's co-pending application. These techniques include methods for fabricating components to 
resist tampering, methods for detecting tampering, and methods for eliminating data when tampering is detected. It 
will be appreciated that, although tamper-proofing is a most desirable feature of the present invention, it does not 
enter into the normal operation of the invention and, as such, is beyond the scope of the present description. 
[0024] In this description, the term 'trusted', when used in relation to a physical or logical component or an 
operation or process, implies that the behaviour thereof is predictable under substantially any operating condition 
and highly resistant to interference or subversion by external agents, such as subversive application software, 
viruses or physical interference. 

45 [0025] The term 'host computer 1 as used herein refers to a data processing apparatus having at least one data 
processor, at least one form of data storage and some form of communications capability for interacting with 
external entities, such as peripheral devices, users and/or other computers locally or via the Internet. The term 
'host computer system' in addition to the host computer itself includes standard external devices, such as a 
keyboard, mouse and VDU, that attach to the host computer. 

50 [0026] The term 'document', as used herein, includes any set of data that can be visualised using a host 
computer system. Commonly a document will be a textual document, such as a contract. However, a document may 
comprise graphics, or pictures, instead of, or as well as, text. In general, a document may comprise a single page 
or multiple pages. 

[0027] The term 'pixmap', as used herein, is used broadly to encompass data defining either monochrome or colour 
55 (or greyscale) images. Whereas the term 'bitmap' may be associated with a monochrome image only, for example where 
a single bit is set to one or zero depending on whether a pixel is 'on' or 'off, 'pixmap* is a more general term, 
which i encompasses both monochrome and colour images, where colour images may require up to 24 bits or more to 
define the hue, saturation and intensity of a single pixel. 



Printed from Mimosa 09/27/01 12:22:23 page -5- 



m 



10 



15 



20 



EP1 056 014 A1 



motherboard - the host computer 100. The ^X^l^^^^^^ 
analogous to the method used to £rt «S (and to the manufacturer of the host computer 100) 

supported by a 'master key", known on.y ™* ^J,^. and used to enable the writing of data to 

. that is written to the trusted display pernor 260 dunng ma djsp(ay ^ wjthout Rnow|edge of 

the trusted display processor 260. Thus, writing 

the master key is not possible. 315 is only accessible by e trusted 

t 0043] It will be apparent from Rgu e 3 that me frame bu ^ ^ f . jQd 

display processor 260 itself, and not by the CPU 200. This ' s an £ ap p ljc ation programs or viru. ,3. cannot 
slncfit is imperative that the CPU 200. or. ^^^^^^^^^^^ >Z°™ 
modify the pixmap during a trusted operat «J£ rtwou djsp)ay prQcesS0i . 26Q 

^ngTrr — 5 - ^ — 315 " ™ " 

by way of background. Initially, an application W£2^j££) to the operating system. An API typically 
appropriate call, via a graphical API (application W^^SL* ""deriving display functions, such as 
provides a standard interface for an application program t .access p ^ operating system tQ 

provided by Windows NT™ for the purposes f ^'"9 a " ' m ^ ™ the gener ation of graphics primitives 
'make respective graphics *~ J J, T^ed dspL processor 260. These graphics pnm^ves 
specific to a display processor wh.c h f „ ro ™ssor 260 Example graphics primitives might be 'draw a 

are finally passed by the CPU 200 to th e tmste d d.spla V PJJJJJ* x and z witn a colour a v 

^ point x to point y the microcontroUer to prov.de the standard 

Say functus to process the received graphics primitives, specifically: 
25 ^ving from the CPU 200 anc ^J^^^^^IZ^^ 

storing the pixmap data into the frame buffer memory 31 5; and 
105 to display the required image on the screen. 
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he other parts typically being d isp.a y function. andfheVOU 105. mother^ 

rr P ^^™ — e or — " which is conce 

So and the user's smartcard 122^ The processing ^^"S^cSU- a processor 400 for enactmg 
preferred embodiment is illustrated .n Figure 4 ■ Jhe Jjooew ejJJ^ of P data and verification of s-gnatures 
standard encryption and decryption ^ct.ons to S V^^^ 

received from elsewhere. In the present embod.ment the P rocessor » vjg asynchron ous protocols spectfied 

Operating system and is arranged to communicate with ^ ^ e « ° rjse y s non . vo latile memory 420. for 
Through ISO 7816-3. 4. T=0. T=1 S sc , used for digitally signing 

example flash memory, containing an identifie l sc of he ^ smancara i k ^ ^ smartcard ^ 

aSa. and a certificate Cert sc . provided by » i ^^^ ¥ ^^JLm 122 (the same in nature to me 
public-private key pairs and includes the cones ^. 9 smartcard contains 'seal" data SEAL in the non- 

certificate CertopOf the trusted display processor 260)^ Further the smara ssor 260 t0 indicate to the 

SfiTe memol; P 420. which can be represented graph.^y by * f e y d P escribed in detail below In the 

user that a process is operating securely with the " s *l n s ™f™* p whjch was originally selected by the user 
present embodiment, the seal data SEAL is .n he f ornv f^^g* int0 the smarted 122 using well-known 

bn^r^ 43 °- eXamP ' e Stonn9 St3te 
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can be of the plugin type. 

[0037] Figure 3 shows a preferred physical architecture for the trusted display processor 260. In accordance 
with the preferred embodiment, the trusted display processor 260 is a single hardware component having the 
characteristics of a trusted component, providing the standard display functions of a display processor and the 
extra, non-standard functions for generating digital signatures and providing a trusted user interface. The skilled 
person will appreciate that the functions could alternatively be physically split into two or more separate physical 
components. However, it will be appreciated on reading the following description that integration of all functions 
into a single trusted component provides a most elegant and convenient solution. 
[0038] According to Figure 3. the trusted display processor 260 comprises: 

a microcontroller 300; 

non-volatile memory 305. for example flash memory, containing respective control program instructions (i.e. 
firmware) for controlling the operation of the microcontroller 300 (alternatively, the trusted display processor 
260 could be embodied in an ASIC, which would typically provide greater performance and cost efficiency in mass 
production, but would generally be more expensive to develop and less flexible); 

an interface 310 for connecting the trusted display processor 260 to the PCI bus for receiving image data (i.e. 
graphics primitives) from the CPU 200 and also trusted image data from the smartcard 122, as will be described; 

frame buffer memory 315, which comprises sufficient VRAM (video RAM) in which to store at least one full image 
frame (a typical frame buffer memory 315 is 1-2 Mbytes in size, for screen resolutions of 1280x768 supporting up 
to 16.7 million colours); 

a video DAC (digital to analogue converter) 320 for converting pixmap data into analogue signals for driving the 
25 (analogue) VDU 105, which connects to the video DAC 320 via a video interface 325; 

an interface 330 for receiving signals directly from the trusted switch 135; 

volatile memory 335, for example DRAM (dynamic RAM) or more expensive SRAM (static RAM), for storing state 
30 information, particularly received cryptographic keys, and for providing a work area for the microcontroller 300; 

a cryptographic processor 340, comprising hardware cryptographic accelerators and/or software, arranged to 
provide the trusted display processor 260 with a cryptographic identity and to provide authenticity, integrity 
and confidentiality, guard against replay attacks, make digital signatures, and use digital certificates, as will 
35 be described in more detail below; and 

non-volatile memory 345. for example flash memory, for storing an identifier l DP of the trusted display processor 
260 (for example a simple text string name), a private key S DP of the trusted display processor 260. a certificate Cert 
DP signed and provided by a trusted third party certification agency, such as VeriSign Inc., which binds the 
4Q trusted display processor 260 with a signature public-private key pair and a confidentiality public-private key 

pair and includes the corresponding public keys of the trusted display processor 260. 



w 
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45 



[0039] A certificate typically contains such information, but not the public key of the CA. That public key is 
typically made available using a 'Public Key Infrastructure' (PKI). Operation of a PKI is well known to those 
skilled in the art of security. 

[0040] The certificate Certop is used to supply the public key of the trusted display processor 260 to third 
parties in such a way that third parties are confident of the source of the public key and that the public key is a 
part of a valid public-private key pair. As such, it is unnecessary for a third party to have prior knowledge of, or 
to need to acquire, the public key of the trusted display processor 260. 

50 [0041] The trusted display processor 260 lends its identity and trusted processes to the host computer and the 
trusted display processor has those properties by virtue of its tamper-resistance, resistance to forgery, and 
resistance to counterfeiting. Only selected entities with appropriate authentication mechanisms are able to 
influence the processes running inside the trusted display processor 260. Neither an ordinary user of the host 
computer, nor any ordinary user or any ordinary entity connected via a network to the host computer may access or 

55 interfere with the processes running inside the trusted display processor 260. The trusted display processor 260 has 
the property of being "inviolate". 

[0042] Originally, the trusted display processor 260 is initialised with its identity, private key and 

certificate by secure communication with the trusted display processor 260 after it is installed onto the 
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parallel, although it is not shown, the control process 520 re iceives _ any grap h plication process 5 00 

primitives process and forwards them onto the generate p.xmap process^ 52£ The caH from me app P 

to sign a document includes the co-ordinates (a.b.c.d) of the edges 0 ^ d ^S e J°* I i l0W or of 6 Arbitrary 

ordinates general.y enables the signing of the en -re surface of the screen, a comp.ete wu ndo Jf 

part of the screen. The application process 500 then waits for the control process 52U to retu 

the image. ~»„»mi nm rp« 520 forces the image that is to be 

be certain that what he sees is what he is signing at all times ^"^"^JJ J" fu J her graphics primitives. 

^^SL^ ^rrhSd ^T~- JgrapSics primes process, or 
any other process executing on the CPU 200. while the issj^ fe 

[0058] Once the document image has been made static, in step 606. the contra process , 

Sap process 527. including in the call the S^^J'^i'w S ^^JSlSLr^r^io. 

.odify the pixmap to highlight the f^^^^^ inserted t the smartcard 122 reader 120. as 

LSned 1 °by thwart 3 ^^7^^ Mi 

f P tne smartcard 122 is inserted in time, or is already present, •^P^STE the seal proceS s 524 calls the 
[0 059] Next, in step 618. the control process 52 ^^^^^^^^ ^ P rocesS 520 
smartcard process 525, to recover the seal data 540 from the smartcard ^ J f m sea , 

calls the generate pixmap process 527 to display l-STiSSiS^^^^^ P^ ocessor 260 
data 540 is being attempted. In steps 618 and ^he ^smartcard process 525 of me t . c P J |enge/reS p 0nse . 
and the display processor process 542 of the smartcard 122 interaci u g {he CQntr0| 

techniques to enact mutual authentication and pass the seal data 1 540 frc m wj „ now be descrjbe d 

process 520. The details of the mutual authentication process and pass.ng of the seal data 54U win 

with reference to Figure 7. reauest REQ1 to the smartcard 122 to return the 

[0060] According to Figure 7, the smartcard process 525 sends a reques : Ktui _to challenge to the 

lea. data SEAL 540. The display processor P-cess 542 J^^^^^^ with nonce R„ signs 
smartcard process 525. The smartcard process =25 generates a nonce R 2 and ^atena R 
the concatenation R,||R 2 with its private key to produce a s.gnature sS DP (R,||R 2 ). and returns _tne 2 
he signature sS DP ( Rl |,R 2 ) and the certificate Cert back to the 1 display prooesso^ ^^^^SS^Sk 

roncSenation^R., to pte that the sea. request came from the expected trusted display processor 260 and that 
^trusted S^Tprotect the user from deception caused by replay of old but genuine signatures 

(called a 'replay attack') by untrustworthy processes. concatenates R, with its seal data SEAL 540. 

0062] The display processor process 542 of the smartcard 1 22 then <»"^"°^ ™ encrypts tne seal 

signs the concatenation R 2 ||SEAL using its private key Ssc oP^as^re ^"JSwnS. nonce R, the 
data SEAL 540 using its private key S sc to produc a encrypted ^^^l^Si^Sm^ro the smartcard 
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(such as received keys) and providing a working area for the processor 400. and an interface 440, for example 
electrical contacts, for communicating with a smart card reader. 

[0049] Seal images can consume relatively large amounts of memory if stored as pixmaps. This may be a distinct 
disadvantage in circumstances where the image needs to be stored on a smartcard 122. where memory capacity is 
relatively limited. The memory requirement may be reduced by a number of different techniques. For example, the seal 
image could comprise: a compressed image, which can be decompressed by the trusted display processor 260; a 
thumb-nail image that forms the primitive element of a repeating mosaic generated by the trusted display processor 
260; a naturally compressed image, such as a set of alphanumeric characters, which can be displayed by the trusted 
display processor 260 as a single large image, or used as a thumb-nail image as above. In any of these alternatives, 
the seal data itself may be in encrypted form and require the trusted display processor 260 to decrypt the data before 
it can be displayed. Alternatively, the seal data may be an encrypted index, which identifies one of a number of 
possible images stored by the host computer 100 or a network server. In this case, the index would be fetched by the 
trusted display processor 260 across a secure channel and decrypted in order to retrieve and display the correct 
image. Further, the seal data could comprise instructions (for example PostScript™ instructions) that could be 
interpreted by an appropriately programmed trusted display processor 260 to generate an image. 

[0050] Figure 5 shows the logical relationship between the functions of the host computer 100, the trusted 
display processor 260 and the smartcard 122. in the context of enacting a trusted signing operation. Apart from 
logical separation into host computer 100, trusted display processor 260 or smartcard 122 functions, the functions 
are represented independently of the physical architecture, in order to provide a clear representation of the 
processes which take part in a trusted signing operation. In addition, the 'standard display functions' are 
partitioned from the trusted functions by a line x-y, where functions to the left of the line are specifically 
trusted functions. In the diagram, functions are represented in ovals, and the 'permanent' data (including the 
document image for the duration of the signing process), on which the functions act, are shown in boxes. Dynamic 
data, such as state data or received cryptographic keys are not illustrated, purely for reasons of clarity. Arrows 
between ovals and between ovals and boxes represent respective logical communications paths. 

[0051] In accordance with Figure 5, the host computer 100 includes: an application process 500, for example a 
wordprocessor process, which requests the signing of a document; document data 505; an operating system process 
510; an API 511 process for receiving display calls from the application process 500; a keyboard process 513 for 
providing input from the keyboard 110 to the application process 500; a mouse process 514 for providing input from 
the mouse 115 to the application process 500; and a graphics primitives process 515 for generating graphics 
primitives on the basis of calls received from the application process via the API 511 process. The API process 511, 
the keyboard process 513, the mouse process 514 and the graphics primitives process 515 are build on top of the 
operating system process 510 and communicate with the application process via the operating system process 510. 
[0052] The remaining functions of the host computer 100 are those provided by the trusted display processor 260. 
These functions are: a control process 520 for co-ordinating all the operations of the trusted display processor 260, 
and for receiving graphics primitives from the graphics primitives process and signature requests .from the 
application process 500; a summary process 522 for generating a signed summary representative of a document 
signing procedure in response to a request from the control process 520; a signature request process 523 for 
acquiring a digital signature of the pixmap from the smartcard 122; a seal process 524 for retrieving seal data 540 
from the smartcard 122; a smartcard process 525 for interacting with the smartcard 122 in order to enact 
challenge/response and data signing tasks required by the summary process 522, the signature request process 523 
and the seal process 524; a read pixmap process 526 for reading stored pixmap data 531 and passing it to the 
signature request process 523 when requested to do so by the signature request process 523; a generate pixmap 
process 527 for generating the pixmap data 531 on the basis of graphics primitives and seal image data received from 
the control process 520; a screen refresh process 528 for reading the pixmap data, converting it into analogue 
signals and transmitting the signals to the VDU 105; and a trusted switch process 529 for monitoring whether the 
trusted switch 135 has been activated by the user. The smartcard process 525 has access to the trusted display 
processor's identity data ! DP , private key S DP data and certificate Cert DP data 530. In practice, the smart card and the 
trusted display processor interact with one another via standard operating system calls. 

[0053] The smartcard 122 has: seal data 540; a display processor process 542 for interacting with the trusted 
display processor 260 to enact challenge/response and data signing tasks; smartcard identity data l sc , smartcard 
private key data S sc and smartcard certificate data Cert sc 543. 

[0054] A preferred process for signing a document using the arrangement shown in Figures 1 to 5 will now be 
described with reference to the flow diagram in Figure 6. 

[0055] Initially, in step 600, the user controls the application process 500 to initiate a 'signature request* 
for digitally signing a document. The application process 500 may be realised as a dedicated software program or may 
be an addition, for example a macro, to a standard word processing package such as Microsoft's Word. In either case, 
neither the signature request nor the application process 500 need to be secure. When the user initiates the 
signature request, he also specifies the document to be signed, if it' is not one which is already filling the whole 
screen. For example, the document may be displayed across a part of the full screen area or in a particular window. 
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524. to the control process 520. 

[0063] Returning to Figure 6. in step 622. when the control process 520 receives the seal data SEAL 540, it 
forwards the data to the generate pixmap process 527. and instructs the generate pixmap process 527 to generate a 
seal image and use it to highlight the document to be signed, as will be described below with reference to Figure 

5 I0d. Then, in step 624. the control process 520 instructs the generate pixmap process 527 to display a message to 
the user asking whether they wish to continue with the signing operation. This message is accompanied by a ten 
second countdown timer COUNT. If the countdown timer expires, in step 626. as a result of not receiving a response 
from the user, the control process cancels the signing operation, in step 628, and returns an exception signal to 
the application process 500. In response, the application process 500 displays an appropriate user message in step 

10 629. If. in step 630. the user responds positively by actuating the trusted switch 135 within the ten second time 
limit, the process continues. The authorisation to continue could alternatively be supplied over an unreliable 
channel, rather than by using a trusted switch 135. or even using appropriate software routines, providing a 
reasonable level of authentication is used. Alternatively, it may be decided that the mere presence of an authentic 
smartcard may be sufficient authorisation for the signing to occur. Such an alternatives are a matter of security policy. 

?5 [0064] Next, in step 632, the control process 520 instructs the signature request process 523 to request the 
signing of the document image; the signature request process 523 calls the read pixmap process 526 to request return 
of a digest of the pixmap data of the document to be signed; and the read pixmap process 526 reads the respective 
pixmap data, uses a hash algorithm to generate a digest D PIX of the pixmap data and returns the digest to the 
signature request process 523. Additionally, the read pixmap process 526 generates 'display format data' FD, which 
includes information necessary to reconstruct the image from the pixmap data into a text-based document at a later 

20 time (FD is not essential, since the document text may not need to be reconstructed), and returns this also to the 
signature request process 523. For example, the display format data FD may include the number of pixels on the 
screen surface and their distribution, such as '1024 by 768', and the font type and size used for the text (if the 
document is text-based) in the document (at least some of this information may instead, or in addition, be contained 
in a document 'summary', as will be described below). In steps 634 and 636, the signature request process 523 

25 interacts with the display processor process 542 of the smartcard 122 using well-known challenge/response processes 
to generate an individual signature of the document, as will now be described in detail with reference to the flow 
diagram in Figure 8. 

[0065] According to Figure 8, the smartcard process 525 generates a request REQ2 for the smartcard 122 to 
generate a signature of the digest D P)X and display format data FD. The display processor process 542 of the smartcard 

30 122 responds by generating a nonce R 3 and sending it to the smartcard process 525 with a challenge to return the 
digest D PIX and the display format data FD. The smartcard process 525 concatenates the digest D PIX with the display 
format data FD and nonce R 3 , and signs the concatenation D PIX ||FD||R 3 to produce a signature sS DP (D PIX ||FD||R 3 ). The 
smartcard process 525 then sends the concatenation D PIX ||FD||R 3 and its respective signature sS DP (D PIX ||FD||R 3 ) to 
the display processor process 542 of the smartcard 122. The display processor process 542 uses the trusted display 

35 processor's public key (which it has already received in the seal data 540 exchange) to verify the trusted display 
processor's signature sS DP (D Prx ||FD||R 3 ) and nonce R 3 , to prove that the digest is the current image digest. The 
display processor process 542 signs the digest of the pixmap D PIX and the display format data FD. using its private 
key. to produce two signatures sS sc (D PIX ) and sS sc (FD) respectively. The display processor process 542 of the 
smartcard then returns the signed digest sS sc (D Plx ) and signed display format data sS sc (FD) to the smartcard process 

40 525 of the trusted display processor 260. The smartcard process 525 next verifies the digest D PIX and display format 
data FD, using the smartcard's public key (which it already has as a result of the seal data 540 exchange), and 
verifies the smartcard's signature, to prove that the smartcard is still online. 

[0066] Returning to Figure 6. in step 638, the smartcard process 525 of the trusted display processor 260 
concatenates the pixmap PIX, the smartcard's signed versions of the pixmap digest sS sc (D P(X ) and display format data 
45 sS sc (FD) to form an individual signature PIX||sS sc (D PIX )||sS sc (FD) of the image, and returns it. via the signature 
request process 523, to the control process 520, which returns the individual signature to the application process 
500. The application process 500 stores the individual signature, in step 640. and responds with a further call to 
the control process 520 to 'summarise the signing' operation in step 642. The purpose of a summary is to complete 
the signature, as will be described with reference to the flow diagram in Figure 9 and also the example summary below: 
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back to the application process 500 until the user actuates the trusted switch 135 again, typically in response to 
another user message, which, this time, would not have a timeout period. This would give the user more time to 
review the static document image before returning the host computer to standard, non-trusted operation. 
[0073] In order to verify a signed document, both the individual signature PIX||sS sc (Dp, x )||sS sc (FD) and the 

5 summary SUM||sS sc (D SUM ) must be verified. Such verification methods are well known to those skilled in the art of 
security. For example, the signature on the digest of the pixmap sS sc (D P | X ) is verified using the public key of the 
user, which is publicly available and preferably contained within a digital certificate Cert sc supplied by a certification 
authority. The verified digest is then compared with a value obtained by recomputing the digest from the pixmap, 
where the digest is generated using a standard, well-known and defined hash function. If the match is exact, the 

10 signature has been verified. Other signatures, including the summary, are checked in the same way. 

[0074] A preferred~method of enabling a person to verify the wording of the signed document is to translate the 
pixmap back into an image. This requires an application, or indeed a trusted display processor 260, to load the 
pixmap data PIX into the frame buffer memory 315 of a respective host computer 100. This allows a person to view the 
document that the signer has signed. 

[0075] The stages of highlighting a document to be signed will now be described with reference to Figures 10a to 
10d. 

[0076] In the preferred embodiment, the seal data SEAL comprises a pixmap of a trusted image. For example, as 
shown in Figure 10a, the pixmap of the seal data 540 defines a 'smiley face' 1000. Figure 10b illustrates an image 
1005 of an exemplary documentDod to be signed, in a window 1010 of the screen (not shown). As a first highlighting 
step, after the image has been made static but before the seal data has been received, the trusted display processor 
260 highlights the document to be signed by superimposing a frame 1020 around the document image 1005, as 
illustrated in Figure 10c. Also, where a smartcard 122 is not present, a user message 1030 asking the user to insert 
his smartcard is displayed accompanied by a ten second countdown timer 1035, as also illustrated in Figure 10c. Next, 
when the smiley face pixmap image is retrieved from the smartcard 122. the trusted display processor 260 embellishes 
the frame 1040 with multiple instances 1045, or a mosaic, of the smiley face, as shown in Figure 10d. In addition, 
25 as shown in Figure 10d. the trusted display processor 260 generates a further user message 1050, accompanied by a 
ten second countdown timer 1055, asking the user whether they wish to proceed with the signing process. This 
embellished frame 1040 both indicates to the user that the correct static image area is being acted on and provides 
the user with a high level of confidence that the trusted display processor 260 is fully in control of the signing 
process; the presence of the user's own seal image provides confidence to the user that the message has come from 
30 the trusted display processor 260 rather than from some other (possibly subversive) software application or hardware 
device. 

[0077] Figures 10e and 10g illustrate alternatives to the 'frame' visual effect illustrated in Figures 10c and 
10d. In Figure 10e, four single seal images 1060 are positioned at the corners of the static document image using 
the co-ordinates provided by the application process 500, to define the static image area. In Figure 10f, the static 
35 image is defined by modifying the background thereof to show a single seal image. In Figure 10g, the static image is 
defined by modifying the background thereof to show a mosaic of seal images. It is expected that the skilled reader 
will be able to think of other visual effects by which the static image may be highlighted in the light of the 
present description. In addition, it may be desirable to include further status messages during the signing 
operation, for example "Retrieving seal data 540 now....", "Generating document signature now....", etc. 
[0078] It will be appreciated that the trusted display processor 260 needs to be able to display the seal 
image(s) and the messages in the correct places on screen. Clearly, the seal image and the message images are 
temporary, to the extent they appear during the signature process and disappear thereafter. There are well-known, 
standard display techniques for overlaying a first image with a second image, thereby obscuring a part of the first 
image, then removing the second image and restoring the portion of the first image that had been obscured. Such 
techniques are used as a matter of course in normal windows environments, for example, where multiple windows may 
overlap one another. The trusted display processor 260 is arranged to implement one of more of these standard 
techniques for the purposes of superimposing the seal image(s) and the message images over the standard display. 
[0079] In some scenarios, it may be that a document is too large to fit all at once onto the VDU 105 screen and 
still be easily read by a person. Obviously, for the present embodiment to be practical, it is essential that a user 
can very clearly read the document before signing it. Therefore, the document can be split into multiple screen 
50 pages, each of which needs to be signed and cryptographically chained to the signature of the previous page, as will 
now be described. 

[0080] First the application process 500 causes the image of the first page to be displayed and makes a call to 
the trusted display processor 260 for signing as before. When the trusted display processor 260 returns the 
individual signature, instead of requesting a summary, the application process 500 instructs the trusted display 
55 processor 260 to display the image of the second page and sign the image. Clearly, in this case, the trusted display 
processor 260 is arranged to support such a request by the application process 500. Only after ail images have been 
signed and returned to the application process 500 does the application process 500 issue a request for a summary. 
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[0090] An enhancement to the process for signing a document is that, prior to signing the pixmap data, the 
trusted display processor 260 compresses the pixmap using a lossless compression algorithm so that the overheads 
associated with storing and sending the individual signature are reduced. 

[0091] The pixmap may be compressed by standard compression algorithms, for example a codeword-based 
5 algorithm applying LZ-1 or LZ-2 compression. Alternatively, a technique similar to OCR (optical character 
recognition) may be used to compress the pixmap. In this case, the situation differs from conventional OCR in that 
the input data has been perfectly 'scanned', albeit at a lower resolution than in conventional OCR. The OCR- 
compressed version of the pixmap may be generated by 'blob-matching' to create an alphabet for the pixmap, 
constructing a pixmap of each character in the alphabet, and constructing a message using those characters, such 
? 0 that the message represents the original pixmap. This means that the pixmap can been compressed to a new alphabet 
and a message written in that alphabet. Since there are, obviously, no errors nor ambiguity in the pixmap data, 
this is a lossless compression method. 

[0092] Another way of reducing the size of the image pixmap is by representing the image as a pure black and 
white image, requiring only a single bit - set to zero or one - to define whether a pixel is black or white. 
Otherwise, the document image is represented as a full colour image, where each pixel may typically require up to 24- 
bits. Obviously, this technique may be suitable for simple, black and white text-based documents. However, it would 
not be appropriate for colour documents or images. 

[0093] At any time, the document image may be converted back into a text-based document using an OCR-type 
process to reconstruct a standard digital textual representation of the document. This technique cannot be used in 
the signature, since the textual mapping may be incorrect, but can be used by the receiver of a signed document to 

20 convert it back into a standard digital textual representation (such as ASCII) for subsequent machine manipulation. 
In preferred embodiments, the trusted display processor 260 is equipped to enact OCR document recovery. 
[0094] To enact OCR, an OCR alphabet is generated in a standard fashion and is then matched to stored fonts and 
hence converted to a standard character set. As in conventional OCR, ambiguous matches may be retained as a 
pixmap and flagged for conversion by the user. (This is unlikely, particularly if font type and size information has 

25 been supplied in the display format data FD, because there is no error in the data.) In cases of extreme caution, 
the entire reconstructed document should be manually checked by a person against the view of the document that the 
signer intended to sign. 

[0095] Preferably all document reconstruction processes are done by processes that are trusted. 
[0096] The preferred embodiment described above relies on the premise that the trusted display processor 260 has 
30 direct and exclusive access to video data stored in the frame buffer memory 315, beyond the point where the video 
data can be manipulated by host computer 100 software, including the operating system. This implies that the video 
data cannot be modified unless the trusted display processor 260 makes the modification. 

[0097] It will be appreciated that not all computer architectures are arranged in this way. For example, some 
computer architectures are arranged such that the frame buffer memory forms a part of the main memory, thus forming 
35 a single address space (SAS) display system. One benefit of such a system is that both the CPU and the display 
processor can access the frame buffer memory and share the graphics operation overhead, thereby improving graphics 
performance. Clearly, an implementation of the present invention in such a SAS system cannot rely on the premise that 
the buffer memory is safe during signing, since the CPU can still access the memory. However, there are many ways in 
which such a SAS system may be modified to support implementations of the present invention. For example, the 
memory could be provided with a control line from a trusted display processor such that, during a signing operation, 
the memory is prevented from being updated by data from the CPU. The memory devices themselves are preferably 
modified so that they include the extra logic to perform this function. Alternatively, access to memory is blocked 
by other logic circuits inserted into the normal control path of the memory. Such systems, therefore, rely on the 
modified premise that the video data in the frame buffer memory can only be modified, other than by the trusted 
display processor, with the permission of the trusted display processor. Clearly, this premise is as valid for 
secure operation as the first premise, as long as the system is truly secure. 
[0098] In other architectures, for example in simple graphics environments, the functionality of a display 
processor may form part of the operating system itself, thereby removing the requirement for separate display 
processor hardware. Clearly, in this case, the graphics overhead put on the CPU will be higher than in a system with 
separate display processor hardware, thereby limiting the graphics performance of the platform. Clearly, there is 
50 then no place for a 'trusted display processor* as such. However, it will be apparent to the skilled person that the 
same function as provided by the trusted display processor, that of protecting the frame buffer memory and 
interacting with a smartcard, can be implemented using an appropriate trusted component, which controls the display 
system (in whatever form) during signing. 

[0099] In other embodiments of the invention, in addition or alternatively, the trusted display processor (or 
55 equivalent) includes an interface for driving a trusted display. The trusted display might be, for example, an LCD 
panel display. In the same way that the trusted switch provides a trusted means for a user to interact with the 
trusted display processor, the trusted display can provide a trusted means for feeding back information to the user 
other than via the standard VDU. For example, the trusted display might be used to provide user status messages, as 
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4. A data processing system according to claim 3. further comprising a secure token reader for reading data from 
and/or writing data to a removable secure token, and a removable token containing data characterising the trusted 

5 image, wherein the trusted component comprises means to receive said data from the secure token. 

5. A data processing system according to claim 3 or claim 4. wherein the trusted component and the secure token 
each comprise means to interact with the other in order to execute the trusted process. 

0 6. A data processing system according to claim 5. wherein the trusted component comprises means to control the 
display processing means to combine the trusted image with the main image to highlight at least a portion of the 
main image as being associated with execution of the trusted process. 

7. A data processing system according to claim 6. wherein the trusted component comprises means to prevent 
, modification by the display processing means of at least the highlighted portion of the main image substantially 

while the data processing system is executing the trusted process. 

8. A data processing system according to any one of claims 5 to 7, wherein the trusted component comprises means 
to interact with the secure token to execute a trusted process which includes generating a digital signature 
characteristic of at least a portion of the main image. 

9. A data processing system according to any one of claims 4 to 8, wherein the trusted component comprises means 
to verify the identity of the secure token. 

10. A data processing system according to any. one of claims 4 to 9, -wherein the secure token comprises means to 
verify the identity of the trusted component. 

11. A data processing system according to any one of claims 4 to 10, wherein each of the trusted component and the 
secure token include non-volatile memory. 

12. A data processing system according to claim 11. wherein the trusted componentand the secure token each hold a 
respective private cryptographic key in the respective non-volatile memory. 

13. A data processing system according to claim 12, wherein the trusted component and the secure token each 
contain a digital certificate including a public key which forms a private/public key pair with their respective 
private key. 

14. A data processing system according to claim 13. wherein the trusted component and the secure token each 
comprise means to receive encrypted data from the other and use their respective private keys to decrypt the 
encrypted data and/or verify that the encrypted data was encrypted using the corresponding public key. 

15. A data processing system according to any one of claims 4 to 14, wherein the data characterising the trusted 
image is stored by the secure token in compressed form and the trusted component comprises means to 
decompress the data. 

16. A data processing system according to any one of claims 4 to 15, wherein the data characterising the trusted 
image is stored by the secure token in encrypted form and the trusted component comprises means to decrypt the 
data and/or verify that the data was encrypted using a corresponding encryption key. 

17. A data processing system according to any one of claims 4 to 16, wherein the data characterising the trusted 
image comprises a series of instructions and the trusted component comprises means to interpret the instructions 
in order to generate the trusted image data. 

18. A data processing system according to claim 6, wherein the trusted component controls the display processing 
means to highlight the main image, or portion thereof, by producing one or more of the following visual effects: 

a border, or an indicator (or indicators) defining a border, characterised by the trusted image and placed 
at least partly around the main image or portion thereof; 
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. a background pattern characterised by the trusted image forming at .east part of the background of the main 
image or portion thereof; 

an image characterised by the trusted image formed within the main image or portion thereof: and/or 
a text message characterised by the trusted image formed within the main image or portion thereof. 

19 . a data processing system accord.ng to any one of Cairns 3 to 18. wherein the disp.ay processing means 
comprises: 

frame buffer memory; 

a pixe. generator to generate pixe. data representative of the mam image on the basis of the signa.s received 
from the main processing means, 

a frame buffer refresher to update the pixel data in the frame buffer memory; and 

with the main image, 
programmed microcontroller. 

22, A dal a posing s y s,.n, acceding >0 .n, one o, m p.e=« g d»™». ««* the «~d co m pon e n, » *np~ 
resistant. 

23. A system comprising: 

main processing means for executing at least one application process: 

means for executing a trusted process in a trusted operating mode and means for generating user feedback 
signals; 

at least one user feedback device; and 

user feedback processing means for receiving said user feedback signa.s and generating respective signa.s 
for driving the user feedback device, 

operating in a trusted operating mode. 

24. A method for providing a trusted user interface in a data processing system, comprising, 
executing a secure process and generating respective user feedback signals: 

providing user feedback on the basis of the user feedback signa.s in such a way to indicate that the data 
processing system is operating under the secure process. 
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